Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Issue 227 add type in case it's not provided #228

Open
wants to merge 13 commits into
base: master
Choose a base branch
from

Conversation

shshashwat
Copy link
Contributor

@shshashwat shshashwat commented Oct 7, 2021

Signed-off-by: Shashwat Sharma shashwat_sharma@dell.com

Change log description
Currently if the type is not provided with addSchema call, for Protobuf and Avro it's being updated after parsing the file but in case of JSON and Custom it's not implemented and it throws retriable exception and keeps on retrying and ultimately after 1 minute the server returns with http status 504.

Purpose of the change
Fixes #227

What the code does
Implement similar behavior to Avro and Protobuf and update type if the same has not been provided with the API call addSchema

How to verify it
addSchema of JSON or Custom type without providing the argument "type" but the same should be reflected

@shshashwat shshashwat marked this pull request as ready for review October 7, 2021 15:40
@shshashwat
Copy link
Contributor Author

shshashwat commented Oct 9, 2021

Further update is that the update entries via the wirecommand fails if the "type" is not provided and this call is inside a retriable block and hence the code retries on fail and keeps on repeating the same unless the Server closes the connection with HTTP 504.
In case of AVRO and Protobuf there is a defined key which is used to update the "type" if the same has not been provided with the request call. Same logic can not applied to Custom and Json hence we will update the value with namespace and group.

Copy link
Contributor

@shrids shrids left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM apart from a comment making the log lines more precise.

@pbelgundi
Copy link

Further update is that the update entries via the wirecommand fails if the "type" is not provided and this call is inside a retriable block and hence the code retries on fail and keeps on repeating the same unless the Server closes the connection with HTTP 504. In case of AVRO and Protobuf there is a defined key which is used to update the "type" if the same has not been provided with the request call. Same logic can not applied to Custom and Json hence we will update the value with namespace and group.

Do we know why WireCommand.UpdateTableEntries fails when type is null or empty?
We noticed that it failed with a badkeyversion exception, which indicates the failure was due to inappropriate version being passed. How is this related to type feild being null/empty.

* @param namespace the namespace for the schema
* @return Provided name or Created name for type in SchemaInfo
*/
public static String createTypeIfAbsent(String type, String groupName, String namespace) {

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don;t see the need for this new method.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This removes the redundancy in the earlier code. Further, if need be this can be utilized in future too

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IMO, this method is unnecessary. We could do with directly using NameUtil.qualifiedName(...);

Copy link
Contributor

@kotlasaicharanreddy kotlasaicharanreddy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shashwat and me had tested this on a live cluster and didn't get any 504 error while creating a schema without type/name.

@@ -133,7 +135,8 @@ public SchemaStoreImpl(Groups<T> groups, Schemas<T> schemas) {
@Override
public CompletableFuture<VersionInfo> addSchema(String namespace, String groupId, SchemaInfo schemaInfo, SchemaInfo normalized,
BigInteger fingerprint, GroupProperties prop, Etag etag) {
// Store normalized form of schema with the global schemas while the original form is stored within the group.
// Store normalized form of schema with the global schemas while the original form is stored within the group.
log.info("Add schema called to add a new schema in namespace {} and groupId {}", namespace, groupId);

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here namespace passed by user may be an empty string, but we're adding the schema to default namespace in this case. So the log message should indicate that. Infact this is the best place to set the namespace string to its default value if the user has provided an empty String.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not allowing empty String as value for any parameter can be enforced by specifying the minLength parameter in swagger .yaml file.
See: https://swagger.io/docs/specification/data-models/data-types/

@pbelgundi
Copy link

pbelgundi commented Oct 11, 2021

@shshashwat The real root cause here is that the SchemaInfo.type field that comes in from the user is empty (not null but empty) and while its fine to handle this in the backend a better thing to do would be to force the user to provide a value for this field using some swagger functionality.
Currently the schemaregistry.yaml lists the SchemaInfo.type field as required which basically just adds a NotNull check to the generated class. It may be better to do a Null + empty check and/or add more validations at this layer instead.
You can find the generated classes under io.pravega.schemaregistry.contract.data

* @param namespace the namespace for the schema
* @return Provided name or Created name for type in SchemaInfo
*/
public static String createTypeIfAbsent(String type, String groupName, String namespace) {

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IMO, this method is unnecessary. We could do with directly using NameUtil.qualifiedName(...);

Signed-off-by: Shashwat Sharma <shashwat_sharma@dell.com>
Signed-off-by: Shashwat Sharma <shashwat_sharma@dell.com>
Signed-off-by: Shashwat Sharma <shashwat_sharma@dell.com>
Signed-off-by: Shashwat Sharma <shashwat_sharma@dell.com>
Signed-off-by: Shashwat Sharma <shashwat_sharma@dell.com>
Signed-off-by: Shashwat Sharma <shashwat_sharma@dell.com>
Signed-off-by: Shashwat Sharma <shashwat_sharma@dell.com>
Signed-off-by: Shashwat Sharma <shashwat_sharma@dell.com>
@shshashwat shshashwat force-pushed the issue_227-Custom_Schema_error branch from db04b58 to 1c8021f Compare October 12, 2021 06:34
Signed-off-by: Shashwat Sharma <shashwat_sharma@dell.com>
Signed-off-by: Shashwat Sharma <shashwat_sharma@dell.com>
@shshashwat
Copy link
Contributor Author

The schemaInfo object is an autogenerated file. It takes all parameters from the request payload form UI or even the API. From UI we pass type which is an optional parameter but is mandatory for schemaInfo object and hence during the normalization of schema, we check if there is not a proper value assigned to it we assign the value to this field. The implementation is done earlier for AVRO and Protobuf but for JSON and Custom it was missing hence. Since the AVRO and Proto have a defined structure, we get the value from the file but JSON and Custom can take anything so proving a random UUID for the same.

Signed-off-by: Shashwat Sharma <shashwat_sharma@dell.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Error 504 in case of adding custom schema with no name/type
4 participants